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Sir: 

This is in reply to the Examiner's Answer mailed September 18, 2007. Since section (9) 
"Grounds of Rejection" of the Answer (pages 3-1 1) appears to merely repeat the final Office 
Action mailed January 19, 2007, which has already been discussed in the Appeal Brief filed 
August 17, 2007, this will reply to the "Response to Argument" of section (10) on pages 12-17 
of the Examiner's Answer. 

In the Boot Process of the Cited Langford et al. Reference, a Validity Flag is First Checked 
Before Beginning to Load the Microcode Rather Than Checking for Bit Errors During 
Loading 

Figure 4 of Langford et al. clearly shows that the Pside validity flag is checked at 402 to 
determine whether the microcode stored in the Pside non- volatile memory is valid or not. If 
valid, the microcode is thereafter loaded at 404 into the memory (RAM) for execution. If not 
valid, the Tside validity flag is then checked at 414 to determine whether the second copy of the 
microcode stored in the Tside memory is valid, and, if so, this second copy is loaded at 416 into 
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the memory for execution, (also see also Langford et al., Figure 3.) These flags therefore 
establish that their associated microcode copy was valid when last checked but of course cannot 
reveal any bit errors occurring since that time during storage or during transfer of the microcode 
into the RAM. 

There is no dispute that Langford et al. do not actually check for bit errors in the 
microcode during its loading into the RAM, and they therefore certainly do not suggest 
correcting any bad bits of the microcode by use of an error correction code (ECC). Langford et 
al. do not therefore suggest "identifying any bit errors in the transferred first copy of the 
firmware code" (appealed claim 1). Nor does Langford et al. suggest the subsequent claim 
recitations of either correcting any identified bit errors or loading code from another copy of the 
firmware if the bit errors are uncorrectable. The more specific recitations of independent claims 
17 and 23 of passing the firmware copy through dedicated ECC circuitry during its transfer are 
therefore also clearly lacking. Rather, Langford et al. check a flag before beginning to load a 
copy of the microcode from non- volatile memory into RAM, and, if the flag indicates that the 
microcode is valid, proceeds to load the microcode without any further regard for the possibility 
of bit errors. 

There seems to be some confusion in the briefs between the boot code and the microcode 
of Langford et al, a confusion that was unfortunately contributed to by the Appeal Briefs 
inconsistent use of the terms, which is regretted. One of the boot code copies 304 or 3 14 of 
Langford et al. (Figure 3) is of course initially loaded as 300 into the RAM 302 before one of the 
flags is read. The memory system processor can operate only if there are instructions present in 
memory to tell it what to do. It is this boot code that tells the processor to check the Pside and/or 
Tside flags prior to loading an associated microcode copy into RAM, which is then loaded 
without any further check on the validity of the data bits. 

Indeed, Langford et al. expressly teach against any such bit checking. An advantage of 
using validity flags stored along with their associated microcode data is stressed by Langford et 
al. to save time during loading since it is determined in advance by reading the flag whether the 
microcode is valid or not. (see Langford et al, paragraph 0029, first sentence.) Langford et al. 
appear not to consider the possibility that data bits can be corrupted during storage in the non- 
volatile memory, or that they may be erroneously read from that memory. As a result, Langford 
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et al. do not get even close to suggesting that if bit errors detected in the microcode are 
uncorrectable with use of an ECC, then the second copy of the microcode may be accessed. 
Langford et al. instead teach going down a different path, namely to check validity flags before 
beginning to load the microcode into RAM because it is perceived to allow faster loading. 

The Mere Mention in Smith et al. of Updating ECCs Associated with BIOS Code Being 

Updated Would Not Have Made it Obvious to Modify Langford et al. to Attempt 
Correction of Bit Errors in the Transferred First Firmware Code by Use of ECCs Before 
Loading the Second Copy 

Each of the appealed independent claims 1,17 and 23 specifies that the transferred first 
firmware copy is checked for bit errors and that those errors are corrected if possible, but if 
uncorrectable, at least a portion of the second copy of the firmware code is then transferred into 
RAM instead. Claim 23 recites this aspect of a storage system in the most detail. 

Langford et al, on the other hand, not only does not check for errors while loading its 
microcode but also states that such a check is undesirable because the discovery of an error 
would require that the loading be re-started from the second copy of the microcode, and this 
would take time. (Langford et al., 1 0029, first sentence.) Langford et al. instead rely on reading 
a data validity flag before loading the associated microcode, as discussed above. A process of 
attempting to correct the data errors in the first copy before proceeding to load the second copy 
of the microcode, not even remotely suggested by Langford et al., would require traveling further 
down this rejected path. Langford et al. would most likely consider that the time required 
identify any bit errors that cannot be corrected has been wasted. 

It is not seen how the mere mention by Smith et al. that a checksum or an error correction 
code is updated when the contents of the code with which it is associated are updated (Smith et 
al., % 0047, Ins. 1-5 & | 0052, Ins. 1 1-14) would have made it obvious for one of ordinary skill to 
travel further down the path that Langford et al. has expressly rejected. 
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For these reasons in reply, reversal of the Examiner's final rejection of claims 1-4, 10, 17, 
18, 20 and 23 is solicited. 



Respectfully submitted, 
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